@KiChjang @vstam1

I dont see any usage of AliasOrigin now, and cannot find any restrictions or recommendation for this instruction,
but if we have ClearOrigin before AliasOrigin in XCM message, then it wont work, I dont know maybe it is intended,

just thinking, what if we change:

let origin = self.origin_ref().ok_or(XcmError::BadOrigin)?;
if Config::Aliasers::contains(origin, &target) {

to:

let effective_origin = self.context.origin.as_ref().unwrap_or(&self.original_origin);
if Config::Aliasers::contains(effective_origin, &target) {

would that be a problem or issue?

I was thinking about that as well, but instead of using the original origin (could very easily lead to an origin escalation attack), we could also just have Aliasers::contains accept an Option<MultiLocation> as the origin ML. This will then allow custom logic to be used when the origin register is set to None.

The question with this approach now is to really ask ourselves whether AliasOrigin is a privileged operation or not. To be safe, I've erred on the side of caution and made it so, but it does not necessarily have to be the case if we document it properly, letting other chains know that they absolutely need to know how to handle the None case appropriately in their Aliasers implementation.